1. Field of the Invention
The present invention relates to the field of software development processes and, more particularly, to extending unified process and method content to include dynamic and collaborative content.
2. Description of the Related Art
Modem software development methods employ complex and sophisticated process frameworks which allow many resources to collaborate. One such process framework is the Unified Process or Rational Unified Process (RUP). RUP method contents can often be published as a Hypertext Markup Language (HTML) documents. The published process acts as a guide to tooling, content, people, and resources for users involved in the process. However, the published content is not as flexible and agile as the processes it profiles. As assets change in the process, the published content quickly becomes outdated and requires republishing. However, republishing is time consuming and as a result does not occur frequently. This leads to “frozen” processes that are not extensible and lack currency.
Further, IT professionals who want to provide feedback and collaboration to the methods are often unable to due to the static nature of published content. Consequently, collaboration and feedback occurs independent of the processes which can leave a rift between the user community and process guidance documentation. Because user communities are often key to providing customized process guidance for domain specific adaptations, the lack of feedback and collaboration results in a deficiency of detailed support. When method content remains relatively unchanged, the advantages associated with an agile process are lost. It would be advantageous if method content remained up-to-date and formed a cohesive body of guidance.
Current manifestations of development processes involving a unified process fall short in providing adequate feedback mechanisms from users and practitioners as evident by FIG. 1 (Prior Art) that illustrates a conventional Unified Process. As shown in FIG. 1 (Prior Art), a process engineer 110 can publish a custom method 117 using method composer tool 115. The published custom method 117 can comprise one or more custom methods 122-126. Published custom method 117 can be provided to unified process consumers 130 via unified process server 120. It is not uncommon for consumers 130 to locally store a set of method 117 related documents, not managed by server 120. The local documents can, for example, include in-process documents standards/code as well as method 117 related research and project annotations. These local documents can be shared with team members in an uncontrolled and/or inconsistent fashion. When shared, local document updates 132 can occur.
However, these updates 132 are often isolated to specific consumers unless an optional local unified process server update 140 occurs. Server updates 140 occur infrequently as updates are a static process which is time and resource intensive. Thus a server update 140 can occur only after a substantial delay, which significantly decreases value of shared documents. Additionally, updates generally require the attention of the process maintainer or engineer 110, who may be too overloaded. These factors result in a rigid unified process situation where consumer feedback and consumer created content is handled in an ad hoc manner or untimely fashion.